What & why

Fixes the slow /browse/subject (and any metadata valueList browse: subject/author/language) on ZCU-PUB. Root cause is upstream DSpace #9244: the pre-7.6.3 SolrBrowseDAO requests the Solr facet with limit = -1, so Solr returns every distinct value on every page request and the code discards all but the page. Cost ≈ O(distinct values).

ZCU-PUB has 254,531 distinct subjects, so subject browse measured ~5.25 s mean (peak 11 s) against naos-be.zcu.cz. This backports the upstream fix (PR #10057) — a json.facet terms query with server-side limit/offset/numBuckets — which returns only the requested page plus the exact total.

Full investigation, measurements and reproduction: dataquest-dev/dspace-customers#668.

Changes

Cherry-pick of the two upstream 7.6.x backport commits (clean for the core fix; one trivial import/method conflict in SolrServiceImpl.java resolved to the refactored form):

• fcc650e1a6 — Add limit, offset, and a total-entry-count parameter to the metadata-navigation Solr query (the core fix; touches SolrBrowseDAO, SolrServiceImpl, DiscoverResult, BrowseEngine).
• d6ff41d9f5 — Refactor browse entries facet query to use JSON facet query.

SolrBrowseDAO now builds a json.facet terms facet on <field>_filter with limit/offset/numBuckets:true; DiscoverResult.getTotalEntries() is populated from numBuckets. No change to the date/item (flatBrowse) path.

Notes

• No Solr reindex required — query-side change only; the <field>_filter fields already exist in the 7.6 schema (used by discovery facets).
• ZCU-PUB carries a browse customization (ZCU-PUB/partial-word-match-browsing-using-api); this branch is cut from current customer/zcu-pub HEAD, so that work (if merged) is preserved — please sanity-check partial-word browse after deploy.
• Same bug affects TUL (~2.37 s, 130k subjects); separate PR against customer/TUL. ZCU-DATA runs the same code but is unaffected (40 subjects) — no change needed there.

Verification

• Local mvn -pl dspace-api -am test-compile checkstyle:check → BUILD SUCCESS (compiles + checkstyle clean).
• These commits are already merged upstream (shipped in dspace-7.6.3 / 10.0) and passed upstream CI incl. browse integration tests.

Post-deploy acceptance (re-run against https://naos-be.zcu.cz/server/api):

• GET /discover/browses/subject/entries?page=0&size=20 mean < 500 ms (expect ~100–300 ms), and page=0 ≈ page=5.
• page.totalElements unchanged (254,531) — proves the numBuckets total wiring is correct.